Um guia do engenheiro para o Docuverso

Introdução

O Projeto Xanadu ™ é o projeto de hipertexto original – uma criação de Ted Nelson e o resultado de um trabalho cuidadoso e apaixonado de inumeráveis ??pessoas inteligentes ao longo de quase sessenta anos. Devido à duração de seu período de desenvolvimento, o projeto gerou e utilizou muitas ideias de importância variável, e ideias particularmente importantes tiveram muitos nomes. Como sua história abrange várias eras da computação, as ideias geradas pelo projeto que antes eram consideradas radicais se tornaram comuns e outras ideias que antes eram comuns se tornaram esquecidas e se tornaram radicais novamente. Durante esse período, a maior parte da documentação disponível ao público foi escrita por Ted e destinada a um público não técnico ou semi-técnico.

Tive a oportunidade de trabalhar no Xanadu® por cinco ou seis anos, depois de passar anos como fã, tentando reunir uma ideia geral do projeto da documentação dispersa. Isso me deu o privilégio de poder pedir a Ted esclarecimentos sobre pontos técnicos e filosóficos, e também me deu uma visão melhor de como diferentes ideias e termos se encaixam em diferentes épocas.

Xanadu tem uma má reputação em muitas comunidades técnicas. Parte disso se deve à popularidade de um artigo de 1995 da Wired sobre o projeto. No entanto, considero que uma questão maior é a tendência do projeto (normal nos anos 80, mas agora muito estranha) de se omitir no sigilo (mesmo no que diz respeito a idéias ostensivamente não secretas) e considerar qualquer divulgação pública de informações em termos de relações públicas. Isso acabou significando que a maioria das informações disponíveis carecia de detalhes técnicos ou tinha seus detalhes técnicos escondidos por trás de uma frente amigável ao público em geral. Com algumas exceções (como o manual do Udonax Green / xu88's FeBe ), não há explicações completas, bem organizadas e divulgadas publicamente sobre conceitos Xanadu voltados para engenheiros. Os engenheiros, como efeito colateral, não conseguiram entender como certas ideias se encaixam e preencheram lacunas na explicação com idéias já familiares a elas.

Os conceitos de Xanadu são, em grande medida, um universo alternativo (e alienígena). Eles foram desenvolvidos mais cedo do que os equivalentes em computação geral em muitos casos, e não são amplamente compreendidos fora da comunidade de desenvolvedores antigos e atuais da Xanadu.

Eu pretendo escrever o guia que eu gostaria de ter lido, antes de Ted me encontrar e me convidar para o projeto. Com alguma sorte, isso esclarecerá alguns conceitos errôneos, apresentará algumas idéias não familiares e preparará pessoas interessadas em participar do projeto com experiência suficiente para entender rapidamente a documentação interna.

Eu estarei cobrindo apenas projetos dos quais tenho profundo conhecimento – seja trabalhando neles, consultando-os ou imergindo em sua documentação. Isso deixa grandes lacunas na cronologia (como xu92 / Udanax Gold), e isso significa que não posso cobrir adequadamente os projetos iniciados após 2017 (incluindo a atual demonstração baseada na web). Vou descrever alguns projetos e idéias de passagem que eu não tenho conhecimento detalhado, devido à sua importância – incluindo OSMIC, xu92 e especializados tipos de enfilade xu88 como o POOMfilade; no entanto, minha breve descrição não deve ser considerada completa ou precisa. Vou tentar marcar esses casos com clareza.

Em alguns casos, tenho escrito independentemente implementações de código aberto de algumas estruturas de dados ou algoritmos desenvolvidos no Projeto Xanadu ™. Eu fornecerei links para estes quando eu os tiver. Eles são planejados como auxílios didáticos – exemplos claros de implementações – e frequentemente faltam otimizações ou integrações com outros recursos; por conseguinte, não devem ser considerados como implementações completas ou prontas para a produção.

Notas legais

Xanadu®, Project Xanadu ™, ZigZag ™ e o logotipo X em chamas são marcas registradas. Quando possível, usarei os seguintes termos genéricos: 'xanalógico' para se referir a um sistema que incorpore idéias do Xanadu ™; 'translit' ou 'transliteratura' para se referir a um sistema xanalógico para representar hipertexto ou hipermídia; 'ZZStructure' para se referir à estrutura de dados e instalações subjacentes dentro de uma implementação do ZigZag ™ na ausência de uma camada de interface do usuário.

Enquanto eu estava em algum momento privado de segredos comerciais pertencentes ao Projeto Xanadu, até onde sei, nada que eu descreva aqui está sujeito à proteção do segredo comercial atual. Além disso, embora tenha escrito código e documentação cujos direitos autorais foram cedidos ao Projeto Xanadu ™, não estou escrevendo isso com base nesse código e na documentação, mas sim com base em minhas lembranças. Pelo que sei, nada explicado aqui é secreto. Além disso, embora houvesse pedidos de patentes apresentados a respeito de algumas das idéias que apresentei, até onde sei, nenhum desses materiais está atualmente onerado por patentes.

Este documento não é oficialmente abençoado pelo Projeto Xanadu ™, e quaisquer imprecisões são minhas. Eu não represento o Projeto Xanadu ™ ou Ted Nelson.

A visão aérea: conceitos-chave

O trabalho em Xanadu pode ser dividido em duas esferas gerais: transliteratura, que envolve hipertexto e hipermídia, e ZigZag ™, que envolve dados muito menores. Esses reinos interagem muito ocasionalmente (veja minha seção sobre ZZOGL / FloatingWorld), mas na maioria das vezes as tecnologias envolvidas permanecem separadas, e elas têm preocupações e filosofias distintas e quase contraditórias.

Se quiséssemos encontrar um equivalente muito difícil no reino da computação normal, a transliteratura seria o processamento de texto, enquanto o ZigZag ™ seria o uso de planilhas e bancos de dados.

A transliteratura, em todas as suas encarnações, envolve vários conceitos ausentes ou estranhos à computação convencional: endereçamento permanente exclusivo para documentos imutáveis ??e dados de origem, entrega indireta de documentos, conexões visíveis e marcação externa. Todas essas idéias derivam de uma única idéia básica: a manipulação de seqüências imutáveis ??de bytes com endereços permanentes.

O universo do ZigZag ™ é baseado em uma estrutura de dados específica – uma generalização da planilha, em que uma célula pode ter conexões ao longo de várias dimensões nomeadas arbitrariamente.

Vou me concentrar na transliteratura deste documento porque ele tem um histórico mais longo e mais conceitos associados a ele. É também o que a maioria das pessoas associa com o nome do 'Projeto Xanadu ™'.

Uma introdução à transliteratura

Transliteratura é o novo nome para o que costumava ser chamado de 'hipertexto'. Especificamente: é uma maneira de pensar sobre texto e outras mídias, e um conjunto de operações e recursos que o modo de pensar torna possível. Os sistemas de hipertexto não-xanográficos, como a World Wide Web, implementam alguns dos recursos mais brilhantes da transliteratura sem compreender ou implementar algumas das ideias centrais e, como resultado, a implementação de outros recursos é impossível, desajeitada ou pouco confiável. Como esses sistemas não-xanográficos dominam a discussão sobre 'hipertexto', nós mudamos o nome.

No final, há três princípios de transliteratura:

  1. Todos os endereços são afixados permanentemente aos dados aos quais eles se referem
  2. Todas as meta-informações (como links, formatação e regras de rearranjo) são distintas das informações originais e, portanto, são armazenadas como um bloco distinto de dados com um endereço distinto.
  3. Todas as operações estão disponíveis para todos os usuários, porque nenhuma operação é destrutiva

Isso se agita de várias maneiras diferentes. Uma é a entrega indireta de documentos.

A entrega indireta de documentos é a ideia de que um documento, como visível para um usuário, é o resultado da combinação de material de várias fontes. A maneira como isso funciona na prática depende da implementação, mas o método atual (usado desde o final do projeto xu92 – portanto, dominante desde 1990, aproximadamente) é o EDL e o EAD. O EDL e o ODL são blocos de dados com endereços permanentes como qualquer outra coisa, mas são interpretados pelo cliente de uma maneira particular.

Um EDL (Edit Decision List) é um conjunto de 'spans' – ou seja, endereços permanentes de blocos de dados com offsets e comprimentos de bytes. (Em xu88, um intervalo era chamado de 'trio' porque tinha três componentes: um endereço, um início e um comprimento.) Os espaços são buscados e colocados juntos na ordem em que ocorrem no documento EDL. O frankenstein resultante é conhecido como "concatexto" (uma junção de "texto concatenado").

Um ODL (Lista de Decisão de Sobreposição) contém regras sobre como exibir conteúdo que esteja dentro de determinadas extensões de endereço. Como um concatexto nunca deve conter nenhum tipo de marcação (mesmo as tags span e div contam como meta-informações sobre quais partes de um documento devem ser divisíveis), toda a formatação é executada usando essas regras. Todas as informações de fonte são fornecidas por um EAD, atribuindo uma fonte ou um estilo de ênfase a um intervalo específico de texto, por exemplo. O ODL também contém informações sobre links (alegando que um ou mais spans estão conectados por um link com algum tipo de link) e sobre o formato (afirmando que algum intervalo deve ser interpretado como uma imagem, um vídeo, um clipe de áudio, etc. .) Informações sobre justificação de texto ou quebras de página também são codificadas no EAD.

Um EDL fornece a capacidade de remixar o documento de outra pessoa, ou criar uma nova versão, sem armazenar uma cópia do conteúdo original de uma forma que não esteja claramente marcada. ( Como uma questão de otimização, é possível que um cache local armazene ou ofereça um concatexto popular e reverta o processo para produzir o bloco original de dados com furos. O que importa é que o posicionamento no endereço original seja canônico.) de uma referência a uma fonte distinta – citando – é chamada de transclusão (uma inclusão de transliteração).

Embora seja de se esperar que o autor de um documento forneça um ODL para acompanhar seu EDL (se necessário), esse emparelhamento é apenas uma recomendação: um ODL é um conjunto de regras de formatação e cada regra pode ser substituída pelo usuário. . Além disso, todos os ODLs carregados no sistema atuam como um conjunto de regras de formatação em relação a qualquer documento visualizado. Dessa forma, é possível abrir muitos documentos distintos e ver suas conexões ocultas (se tiver a sorte de ter ODLs que exibam links entre esses documentos ou suas origens).

No front-end, os links são exibidos como pontes (também chamadas de vigas) entre os trechos conectados de documentos abertos. (Nas implementações em que trabalhei, tínhamos um conjunto de regras configuráveis ??para quais cores o texto e as pontes vinculados eram para tipos de link específicos e geramos processualmente uma cor a partir do hash do tipo de link, se esse tipo não estivesse em nosso banco de dados colorido.) O uso de vigas visíveis entre documentos abertos é chamado de “conexão visível” ou “janelas transponders”.

Todo documento visível é considerado editável, porque a edição desse documento produz uma nova versão com um endereço distinto.

Diferenças entre implementações de translit

Endereçamento e como EDLs e ODLs são armazenados mudou muito após a introdução da web.

O Udanax Green / xu88 , desenvolvido em meados dos anos 80 na Autodesk e lançado em código aberto em 1999, representa a culminação de um conjunto particular de idéias sobre endereçamento iniciado na década de 1970 na itty bitty machine co . Em particular, Green usa uma estrutura de dados chamada ' enfilada ' – um tipo de árvore com regras especiais de busca. O enfilade trabalha em conjunto com um ' endereço de tumbler ' – uma seqüência de números que informa ao servidor como navegar na árvore.

Cada nó da árvore contém zero ou mais subárvores numeradas e cada folha contém uma informação. O servidor usa cada parte do endereço do tumbler para determinar a subárvore para a qual navegar e quando ficar sem números no endereço, ele concatena e retorna os dados de todas as subárvores.

O Green foi projetado para clientes cuja largura de banda, memória e velocidade de processamento eram ruins, e assim foi feito um esforço para colocar o máximo de processamento possível no servidor e fornecer ao cliente algo praticamente pronto para ser exibido.

Udanax Gold / xu92 , desenvolvido depois de Green, usou uma estrutura diferente chamada Ent. Infelizmente, a fonte completa para o Gold não foi liberada, e não posso fornecer muita informação sobre isso. Eu conheci um dos principais autores uma vez e ele me disse que Gold suportava cadeias de assinatura criptográfica para versionamento, de uma maneira semelhante a um blockchain, mas não posso confirmar isso.

A partir dos anos 90, os sistemas de transliteração começaram a usar URLs e HTTP para endereçamento. O XanaduSpace e seu sucessor XanaSpace usaram este sistema, assim como o OpenXanadu baseado em navegador e a demonstração atual baseada em navegador, XanaduCambridge . Isso apresenta alguns problemas. Não é garantido que os dados endereçados por um URL permaneçam estáticos – na verdade, embora o W3C mantenha que alterar os dados endereçados por um URL seja rude e grosseiro, quase todo o conteúdo da Web é dinâmico e os sites têm seu conteúdo completamente substituído em um formato regular. base. Além disso, hospedar o conteúdo do usuário torna-se um problema técnico e (com DMCA) um problema legal. Os sistemas de transliteração baseados em navegador têm um problema adicional: a política de mesma origem dificulta a exclusão de conteúdo de diferentes domínios.

Em meus próprios sistemas xanalogicos, eu prefiro usar sistemas baseados em CAN / DHT como o IPFS. Um protótipo usando o IPFS está aqui .

Outro conceito que existe no XanaduSpace e no XanaSpace é o ' permascroll '. O permascroll é a única violação da regra de que blocos de dados são imutáveis. É um log de conteúdo somente de anexos. A idéia é que, durante a edição, qualquer coisa digitada entraria no permascroll, e o EDL iria transcluir esse conteúdo do permascroll.

Há duas ideias de como o uso de permascroll funcionaria em conjunto com a publicação. Uma é que há uma divisão privada e pública de permascroll – em outras palavras, o conteúdo que está sendo editado na própria máquina de alguém teria endereços no permascroll privado, mas o processo de publicação de um documento anexaria todas as partes do permascroll privado que foram transcluídas por esse documento para um permascroll público (com exceção de qualquer um que já possa estar presente) e o EDL publicado teria seus endereços de span e offsets editados para compensar. O outro usa um único permascroll público que é criptografado usando o método que descreverei posteriormente sob o cabeçalho transcopyright , com seções não publicadas consideradas "não disponíveis para venda".

ZigZag ™ e a ZZStructure

O ZZStructure é relativamente simples: matematicamente falando, é um grafo direcionado com bordas coloridas, onde cada nó pode ter no máximo duas bordas de cada cor – uma indo para fora e outra entrando. Chamamos as células de nós, e chamamos de conexões de bordas. Nós chamamos a cor de 'dimensão'. A direção é 'posward' – out – ou 'negward' – em.

Cada célula, além de ter nomeado pares de conexões para outras células, tem conteúdo (embora esse conteúdo possa estar em branco).

Outra maneira de pensar em uma ZZStructure é que cada sequência de células ao longo de alguma dimensão (chamada de ' rank ') atua como uma lista duplamente vinculada – então uma ZZStructure é um emaranhado de objetos que ocupam diferentes posições simultaneamente em diferentes listas duplamente ligadas.

Dadas essas regras básicas, temos uma estrutura de dados que, dependendo de como você a vê, pode efetivamente expressar um grande número de coisas diferentes.

Uma maneira de ver isso é como uma célula sujeita a propriedades, definida por suas conexões positárias ao longo das dimensões. Isso é semelhante a um sistema de objetos baseado em protótipos e é usado internamente no XanaSpace e em outros lugares como um sistema de configuração.

Uma propriedade particular, ' clone ', é tratada especialmente. Quando você solicita o conteúdo de uma célula, sob o capô, você obtém o conteúdo da célula mais negativa ao longo da classificação 'd.clone' – a ' cabeça ' do d.clone ou ' clonehead '. Os clones (definidos como células que têm um vizinho negward ao longo de d.clone) são tratados como referências ao seu clonehead. Como uma propriedade pode ser um clone de alguma outra célula, o espaço pode ser salvo ou uma propriedade pode fazer referência a um grande grupo inteiro de outras propriedades que podem ser alteradas independentemente.

Usado como um organizador pessoal, ferramenta de mapeamento mental ou banco de dados, esse modelo de propriedade é bastante útil. Na medida em que o ZigZag ™ é usado na prática, geralmente é com uma interface de painel duplo como um organizador pessoal.

Estruturas incomuns podem ser produzidas no ZigZag ™. Por exemplo, um ringrank é um rank circular – não tem cabeça. Uma lista de zíperes é um par de classificações ao longo de alguma dimensão com uma conexão ao longo de alguma outra dimensão – representando uma matriz associativa ou alguma outra correspondência.

Atualmente existem duas implementações oficialmente abençoadas do ZigZag ™ disponíveis ao público: um sistema baseado em console chamado azz e um sistema gráfico chamado gzz . Antes de ingressar no projeto, trabalhei em dois projetos adjacentes do ZigZag ™: o dimscape , um editor gráfico ZZStructure e o iX , um sistema operacional de brinquedo cuja interface de usuário e formato de disco foi inspirado pelo azz.

Implementações oficialmente abençoadas tendem a ter interfaces de painel duplo porque elas tendem a suportar um sistema de interface padronizado baseado em teclado chamado KBLANG, que requer pelo menos dois painéis. O KBLANG baseia-se na divisão de um teclado QWERTY em dois blocos de direção (controlando a célula atualmente destacada em seus respectivos painéis) e usando as teclas restantes para realizar operações ou alternar dimensões visíveis.

Chaves de navegação e comando do KBLANG

Foram feitos alguns esforços para desenvolver linguagens de programação que usam o ZigZag ™ nativamente, a maneira como as linguagens de fórmulas de planilhas aproveitam a estrutura da planilha. Há alguma discussão aqui , e aqui está minha contribuição para o problema .

Transcopyright

Transcopyright é um conceito que recebe muito retorno de pessoas que realmente não entendem o que está tentando fazer. Eu farei o meu melhor para explicar isso, com ênfase especial nas confusões que tenho visto.

Transcopyright é um sistema para monetizar ou controlar a distribuição do material dentro de um sistema de transliteração. Não é DRM, porque se aplica a dados as mesmas regras de propriedade que são aplicadas a objetos: o que você comprou, um possui perpetuamente, incluindo o direito de remixar e lançar remixes.

Ele visa especificamente simplificar as negociações de direitos sobre trabalhos derivados e usa o mesmo modelo que o RiffTrax: os remixers estão fornecendo regras de sobreposição ou reorganização para o material já pertencente às pessoas que baixam o remix. Ele depende de um endereço permanente para isso.

Em um nível técnico, como isso funciona é: quando um trabalho sujeito ao transcopyright é publicado, um bloco único é gerado com o mesmo comprimento de todo o material recém-publicado no trabalho. O material é criptografado com esse bloco único e é o texto cifrado que é publicado. Qualquer um pode ver qualquer extensão do texto cifrado. Qualquer pessoa que queira visualizar uma parte do texto simples deve solicitar essa parte do bloco único do autor ou de algum oráculo confiável.

Um remix ou edição pode ser baixado por qualquer pessoa, mas as partes que o espectador ainda não tem permissão para visualizar serão cyphertext (sujeito a uma entrada de EAD que apaga e fornece informações sobre como adquirir os direitos a ela). Pode-se decidir pagar apenas pelos bytes presentes no remix. Remixes de coisas que o espectador já possui não exigirão uma segunda cópia.

Depois de ter uma cópia do texto original, não há mecanismos técnicos para impedir que você faça o que quiser com ela. No entanto, a etiqueta determina que você não distribua o texto simples ou a chave de criptografia além de um nível razoável, e a lei de direitos autorais normal entra em ação nesse ponto. O software em si não fornece a facilidade de distribuir em seu nome, para o material que você não criou.

ZZOGL / FloatingWorld

O XanaduSpace e o XanaSpace usam um sistema exclusivo para lidar com a exibição, em que um ZZStructure controla o posicionamento, a forma, a cor e o perfil de interação de objetos no espaço 3D. Isso é chamado ZZOGL (para ZigZag OpenGL) ou FloatingWorld (FW para abreviar).

O FW é uma forma extrema do modelo de 'orientação para propriedade' mencionado na seção do ZigZag. Nele, as células correspondem a cabeças de objetos (em torno das quais as propriedades se aglutinam) ou a valores de propriedades.

A partir de uma célula representando o início da estrutura (a cabeça zzogl), uma dimensão representa a ordem de desenho. Nós iteramos objetos ao longo desta dimensão duas vezes. Durante o primeiro passo, calculamos tamanhos e localizações; durante a segunda passagem, desenhamos usando nossos tamanhos e locais calculados.

Cada objeto calcula sua localização com relação a algum outro objeto dentro de um DAG de deslocamento de localização. O tamanho de seus pais em três dimensões é multiplicado por um vetor entre 0 e 1 (o ' pai-mãe ' – o ponto no pai em relação ao qual nos movemos), adicionamos o delta e então o posicionamos em um ponto em nós mesmos ( tamanho * centro).

pos = parent.pos + (parent.size * (parent.center-parentcenter)) + delta- (tamanho * center)

Esse tipo de posicionamento relativo dinâmico possibilitou representar relações relativamente complexas entre objetos. Usamos para exibir os sistemas de transliteração e ZigZag.

Havia alguns tipos de objetos:

  • 'grupos': objetos falsos invisíveis para mover grupos inteiros de objetos ao mesmo tempo
  • 'slabs': prismas retangulares
  • 'vigas': formas bidimensionais tetragonais com uma cor sólida
  • 'tetroids': formas bidimensionais texturizadas que têm a forma de blocos de tetris ou parágrafos de texto (em outras palavras, um retângulo com no máximo dois retângulos menores, encostados na parte superior ou inferior)

Infelizmente, fazer com que o OpenGL processasse grandes quantidades de texto em cima de objetos 3d, ao mesmo tempo em que respondia o suficiente para editar esse texto em tempo real, era um problema difícil e que nunca conseguimos resolver. Como resultado, o XanaduSpace e o XanaSpace nunca tiveram um lançamento.

OSMIC

OSMIC é um sistema alternativo de versionamento de documentos – um sistema baseado em periódicos de uso geral para versionamento baseado em árvore de qualquer sequência de bytes. Cada versão é um endereço em uma lista de etapas. Um passo pode ser um dos seguintes:

  • inserir bytes em um determinado ponto
  • excluir bytes de um determinado ponto

O endereço de uma versão é, como um endereço de tumbler, uma seqüência de números separados por período. Cada vez que uma nova versão é criada, o último número é incrementado. Cada vez que a árvore de versões se bifurca, um novo número é adicionado no final, começando com zero.

Embora seja possível reconstruir uma versão do zero executando o diário, também é possível retroceder para uma versão específica tratando cada exclusão como uma inserção e cada inserção como uma exclusão. Uma revista OSMIC pode ser muito maior que a cadeia de bytes que ela representa, portanto, uma representação compacta é importante. Não tenho conhecimento de nenhum trabalho em uma representação binária compacta de periódicos OSMIC.

Eu não trabalhei com OSMIC, mas uma vez foi sugerido que o XanaduSpace deveria ser adaptado com um sistema OSMIC para armazenar o estado e histórico do sistema ZZOGL (e, portanto, todas as informações internas necessárias para exibir e editar documentos) .

Edição de transliteratura

Existem vários sistemas para edição de transliteratura, alguns deles lançados. Nenhum deles é, a meu ver, satisfatório. Todos são baseados em selecionar e reordenar spans de documentos existentes. Minha implementação é chamada SPANG e destina-se ao uso com o OpenXanadu. O XanaduCambridge tem um sistema menos elaborado e mais manual .

Lançamos um sistema mais natural, em que o texto selecionado poderia ser arrastado para fora de uma janela para criar um novo documento ou arrastado para encaixar no final de um documento (ou no meio de um documento como uma inserção) para produzir transclusões. Sugerimos que você arraste um intervalo de texto selecionado sobre outro intervalo de texto selecionado para produzir um link entre eles.

Esse sistema exigiria um ambiente em que os documentos flutuassem e o texto pudesse ser arrastado entre widgets – em outras palavras, algo com o qual as bibliotecas gráficas de plataforma cruzada com as quais estávamos trabalhando não eram compatíveis.

Formatos

Formatos no disco (para ZZStructures, EDLs e ODLs) estavam constantemente em fluxo enquanto eu estava no Xanadu. Alguns eram, na minha perspectiva como programador profissional, péssimos. A maioria era baseada em pares CSV ou valor-chave. Em alguns casos, eles usaram CSV para campos obrigatórios e notação de valor-chave para campos opcionais.

Eu prefiro um subconjunto de YAML ou JSON para ZZStructures, porque ZZStructures se encaixa bem nesse modelo. No entanto, uma vez que essas estruturas têm hierarquia explícita, elas eram controversas.

De um modo geral, os formatos EDL têm sido uma linha por span, com triplos ordenados (endereço, início, fim). Se as chaves são ou não usadas diferem de especificação para especificação, assim como (ou se) é possível especificar um documento inteiro sem especificar seu comprimento.

De um modo geral, os ODLs são listas de endereços que apontam para arquivos “link”, e esses arquivos “link” contêm um tipo seguido por seções chamadas 'endsets' que contêm um ou mais espaços cada. Geralmente, um link tem um ou dois endsets. Se um único endset tiver extensões não contíguas, o feixe resultante se assemelhará a uma estrela do mar ou a uma mão. Argumentei a favor de arbitrariamente muitos finsets, cada um com muitas extensões arbitrárias. Também argumentei a favor de links unilaterais de comprimento zero, que eu considerava como marcadores. Eu implementei quebras de página no XanaSpace como links unilaterais de comprimento zero.

Houve discussões sobre se é ou não apropriado suportar spans que estão relacionados ao concatexto de algum documento (e, em caso afirmativo, como especificá-lo). Ted tem sido geralmente contra esse recurso, e eu geralmente tenho sido a favor dele – tanto em EDLs quanto em ODLs.

Se você planeja implementar um sistema xanalogical, a compatibilidade com um formato existente não será um problema: não há padrões genuínos, mesmo dentro do projeto. No entanto, você deve considerar os problemas mencionados acima.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *